REMARKS 

This paper responds to the Office Action dated May 2, 2006. 

5 Office Action Paragraph 1 

The Examiner states (paragraph 1, page 2) that the applicant amended claims on October 2, 2005. The 
Examiner is respectfully requested to note that no amendment occurred on that day. The Examiner is 
further respectfully requested to note that the claims pending on October 2, 2005 had not been amended 
10 since at least December 22, 2004. 

Office Action Paragraph 4 

The Examiner expresses the view that claims 13 and 17 are not enabled by the specification. Claims 13 
15 and 17 were in the application when it was filed on December 27, 2000. By an amendment set forth 
above, the text of originally filed claims 13 and 17 has been added to the specification at page 20, 
following line 5. This is not, of course, adding new matter, because the text was in the application on 
the day it was filed. It is suggested that this overcomes any concern as to whether the specification 
now contains enabling language. 

20 

Office Action Paragraph 5 

The Examiner expresses the view that the specification as filed did not provide a written description of 
the invention set forth in claims 13 and 17. Claims 13 and 17 were in the application when it was filed 
25 on December 27, 2000. By an amendment set forth above, the text of originally filed claims 13 and 17 
has been added to the specification at page 20, following line 5. This is not, of course, adding new 
matter, because the text was in the application on the day it was filed. It is suggested that this 
overcomes any concern as to whether the specification now contains a written description of the 
invention set forth in claims 13 and 17. 

30 

Office Action Paragraph 7 

The Examiner expresses the view that claims 13 and 17 are not directed to statutory subject matter. 
The undersigned has carefully considered the guidance provided in Section 2106 of the Manual of 
35 Patent Examining Procedure. 
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Similarly, computer programs claimed as computer listings per se, i.e., the descriptions or 
expressions of the programs, are not physical "things." They are neither computer components 
nor statutory processes, as they are not "acts" being performed. Such claimed computer 
programs do not define any structural and functional interrelationships between the computer 
5 program and other claimed elements of a computer which permit the computer program's 

functionality to be realized. In contrast, a claimed computer-readable medium encoded with a 
computer program is a computer element which defines structural and functional 
interrelationships between the computer program and the rest of the computer which permit the 
computer program's functionality to be realized, and is thus statutory. Accordingly, it is 
10 important to distinguish claims that define descriptive material per se from claims that define 

statutory inventions. 

(Emphasis added.) As such, claims 13 and 17 have each been amended to recite the preferred language 
of "computer-readable medium". It is suggested that this overcomes any concern as to whether the 
15 claims are directed to statutory subject matter. 

Office Action Paragraphs 9-14 

The Examiner expresses the view that all pending claims are supposedly obvious in view of a two-way 
20 combination of US Pat. No. 6,078,948 to Podgorny et al. ("Podgonry") and US Pat. No. 6,804,8 1 8 to 
Codella et al. ("Codella"). In response, the applicant will: 

• briefly review the disclosure relating to the invention; 

• briefly review the content of Podgorny; 

25 • discuss the claims one by one in connection with the cited two-way combination. 

The disclosure relating to the invention 

The invention discloses a messaging system for storing and forwarding messages from and to message 
30 clients. In order to: 

1 . accommodate a very large number of message clients, and 

2. provide redundancy in the case of component failure, 

35 the functionality of the message server is spread out over a server cluster, that is, a number of 
individual machines called nodes. 



The server cluster comprises client manager nodes that handle communication with the message 
clients, and message manager nodes for storing and distributing messages. Thus, the server is a server 
40 cluster embodying a two-tier structure. The nodes in the server cluster are arranged to communicate by 
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a multicast channel. 



The structure of the inventive system is exemplified by the following graph (Figure 1): 




Cluster 



The elements of the structure are defined in the independent claims as follows (reference is made to 
claim 1, but the argumentation applies mutatis mutandis to claims 7, 13, and 17). 

This inventive structure makes it possible to: 

10 

• distribute a multitude of clients over separate client manager nodes, 

• distribute the message handling over separate message manager nodes, and 
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• have each client manager node and each message manager node communicate with all other 
nodes. 

Thanks to this, it further is possible to implement redundant message manager nodes, which in turn 
5 allows for continued operation in case one message manager node fails. 

The content of Podgorny 

Podgorny shows a framework for forming virtual communities having virtual rooms with collaborative 
10 sessions. A mechanism is provided for arranging communication between applications running on 
different clients. For this purpose, a demon program is executed on the client. The demon is 
downloaded as part of a web page and then may communicate (see e.g. Abstract, Fig. 2): 

1 . with client applications running on the client system (and having been launched by the demon), 
15 2. with control logic running on the client system (and having been downloaded by the demon), 
and 

3. with a remote server. 

The demons are part of the clients. The server comprises a room manager which in turn comprises 
20 several rooms. Fig. 12 accordingly shows a server logic 240 comprising rooms 1240a,b,c (see also col. 
15, lines 60-65). A room module 1240 in turn comprises several user modules 1320a,b,c 
communicating with associated demons and with the room's message distribution module 1350 (Fig. 13 
and col. 17, lines 58-62). Only clients connected to the same room may thus communicate with one 
another. 

25 

The communication between the message distribution module 1350 and the user modules 1320a,b,c 
may be effected in the following manner (col. 17, lines 61 col. 18, lines 27): 

1 . incoming messages from a user module 1320a,b,c being forwarded by the message distribution 
30 module 130 to another module, or 

2. outgoing messages being broadcast or unicast to one or more user modules 1320a,b,c. 

The Podgorny structure is shown in the enclosed overview diagram, which is a combination of the 
relevant parts of Figures 2, 12 and 13. 
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US 6078,948 Podgorny et al. 

Synopsis of system Structure, combined from 

■ FIG. 2 (client structure) , 

■ FIG. 12 (server) and 

■ FIG. 13 (room, upside down) 
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This structure has the following features: Each client 210 communicates with an associated user 
module 1320 (Only one client 210a is shown with its internal structure, the other clients have the same 
internal structure). A set of user modules 1320a,b,c is part of the same room 1240a and communicates 
5 with the same message distribution module 1350. The internal structure of further rooms 1240b,c is 
similar, each room being in communication with a number of clients (e.g. room 1240b with clients 
210d,e). The server 240 can accommodate and manage several separate rooms 1240a,b,c, but 
communication between rooms is not contemplated. 

10 Individual machines in the Podgorny system are the clients and the server. 

Differences 

It is thus perhaps instructive to compare and contrast the disclosure relating to the invention with the 
15 disclosure of Podgorny. This will be discussed now in general terms, and then each of the pending 
independent claims will be discussed in detail in connection with Podgorny. Finally, some of the 
dependent claims will also be discussed in some detail in connection with Podgorny. 

First, the invention claims the message system comprising a server cluster comprising client manager 
20 nodes and message manager nodes. Podgorny shows a monolithic server and does not give an 
indication that or how the server should be implemented as a server cluster. 

Second, even if the above argument were disregarded (e.g. by considering the clients to be part of the 
server cluster), the structure of the system disclosed in Podgorny et al. nevertheless differs from the 
25 inventive structure in the following manner: Whereas individual elements or combinations of elements 
from Podgorny and the present invention may indeed be matched, the entire structure as claimed in the 
invention is not disclosed. 

Such individual elements are identified and matched in the Office Action as follows: 

30 

• On page 5, first bullet point, Podgorny's demon logic is identified with the client manager nodes 
of the invention. 

• In the next bullet point on page 5, a number of features are alleged to be relevant to client 
manager nodes (the claim text beginning with "each client manager node of said group of client 



- 17- 



manager nodes comprising ...."). 

However, the text quoted from Podgorny at page 4, paragraph 10, says: 

5 Podgorny teaches a system that "includes logic to establish communication connections with 

demons..." 

These words, when quoted in the original context (Podgorny, column 2, lines 52-52), states that "The 
server includes logic to establish communication connections with demons...". 

10 

(Emphasis added.) Therefore, these features are features of the server and not features of a demon, 
which previously has been identified with a client manager node. Thus, it is respectfully suggested that 
the passage quoted from Podgorny does not disclose the quoted client manager node features. 

15 In following bullet points in the Office Action, it seems that the Podgorny server is identified with the 
message manager nodes of the invention (see e.g. Office Action page 6, the last four lines). 

However, these individual elements from Podgorny cannot be assembled consistently to form the 
structure according to the invention. It turns out that no matter how the Examiner attempts to match up 
20 elements of Podgorny with limitations in the claims (for example Claim 1), the match-up does not 
work. 

Different variants for matching these elements shall now be discussed, and the ensuing contradictions 
shall be shown. It will be helpful if reference is made to the enclosed overview diagram of Podgorny 
25 and to the above figure showing the invention. 

Consider a first way to try to match elements of Podgorny to the claim limitations. 

First way to match: 

30 

• demon = client manager node 

• server = message manager node 

Ensuing contradiction 1 : Claim 1 features a multicast communication channel between the client 
35 manager nodes ("demon") and message manager nodes ("server"). In Podgorny, this layer of 
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communication is denoted as "to demons". These connections are the client-server connections and are, 
by their nature, one-to-one connections. Broadcasting does not make sense here and is not disclosed 
either: The pertinent section in Podgorny that mentions broadcasting (col. 17, line 58 to col. 18, line 
27) refers to the communication between user modules 1320 and message distribution module 1350, 
5 that is, to communication within the server. 



Ensuing contradiction 2: Claim 1 claims a plurality of message manager nodes, whereas Podgorny 
discloses only a single server. 

10 Ensuing contradiction 3: Podgorny shows each demon being located in and therefore associated with a 
single client. The invention claims (emphasis added) 

each client manager node of said group of client manager nodes comprising means for 
connecting to clients , means for managing client connections , means for forwarding messages 
15 received from message producing clients to message manager nodes, and means for forwarding 

messages received from message manager nodes to message consuming clients . 

that is, with clients and connections in the plural form! As is evident from drawing 1 of the present 
application, this capability of one client manager to handle several clients allows to serve a multitude of 
20 clients, whereas Podgorny requires one user module for each client. 



Therefore, the claimed structure of the invention is not disclosed by this interpretation of the terms 
client manager node/ message manager node. 



25 There are other ways in which one could attempt to match up elements of Podgorny with the claim 
limitations. Although these other ways were not raised or suggested in the Office Action, it may 
nonetheless be helpful to explore them and to point out their ensuing contradictions as well. 



Second way to match: 

30 

• demon = client manager node 

• user module = message manager node 

Ensuing contradictions 1 and 3: the same as above. 

35 

Third way to match: 

• user module = client manager node 
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• message distribution = message manager node 

Ensuing contradiction 1 : Podgorny shows each user module being associated, by definition, with a 
single client. The invention claims clients and connections in the plural form, as already described 
5 above (contradiction 3 for the first way to match). 

Ensuing contradiction 2: Podgorny shows only a single message distribution module 1350 that 
communicates with a group of user modules. The invention claims that there is a plurality of message 
manager nodes (that communicates with the client manager nodes by means of a multicast 
1 0 communication channel) . 

Therefore, there is no way, regardless of how the nodes of the invention are matched to one entity or 
the other of the Podgorny structure, in which the complete structure of the invention can be consistently 
mapped onto the Podgorny structure. 

15 

The claims 

With regard to obviousness, it therefore follows, for claim 1, that ... 

20 ... according to the first way to match discussed above (i.e. demon = client manager node, server = 
message manager node), Podgorny does not disclose: 

1 . each client manager node (demon) of said group of client manager nodes comprising means for 
connecting to clients, means for managing client connections, means for forwarding messages 

25 received from message producing clients to message manager nodes (server), and means for 

forwarding messages received from message manager nodes (server) to message consuming 
clients. 

2. the server cluster further containing a group of message manager nodes (server) being 
configured differently from the client manager nodes (demons), said group of message manager 

30 nodes comprising a plurality of message manager nodes (server). 

3. said messages comprising a destination information addressing a destination, said destination 
being at least one of a queue and a topic. 

4. the system further comprising communication channel means for providing a multicast 
communication channel for forwarding messages between said group of client manager nodes 

35 (demons) and said group of message manager nodes (server). 

With regard to point 1, it would be contrary to the teaching of Podgorny to connect the demon ("client 
manager node") to several clients, since the demon is running on a single client and by definition serves 
only this client. It also is physically impossible, since the clients reside at different locations and are 
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arranged to communicate through the server alone (which is the purpose of the entire system). 

With regard to point 2, since the server is identified with the message manager node, Podgorny does 
not suggest providing multiple servers and how to incorporate them into a complete system. 

5 

With regard to point 3, the examiner has already admitted that Podgorny does not show this feature. 

With regard to point 4, since each demon ("client manager node") is assigned to a single client, 
Podgorny discloses point-to-point communication between the demon (on behalf of the client) and the 
10 server ("message manager node") and does not disclose multicasting. Furthermore, since all 

communication has to run through the server ("message manager node"), Podgorny teaches away from 
using multicasting, which would allow demons to communicate directly with each other. 

... according to the second way to match (i.e. demon = client manager node, user module = message 
15 manager node), Podgorny does not disclose 

1 . each client manager node (demon) of said group of client manager nodes comprising means for 
connecting to clients, means for managing client connections, means for forwarding messages 
received from message producing clients to message manager nodes (user module), and means 

20 for forwarding messages received from message manager nodes (user module) to message 

consuming clients. 

2. said messages comprising a destination information addressing a destination, said destination 
being at least one of a queue and a topic. 

3. the system further comprising communication channel means for providing a multicast 

25 communication channel for forwarding messages between said group of client manager nodes 

(demons) and said group of message manager nodes (user module). 

With regard to point 1, the same as for the first way to match holds. 

30 With regard to point 2, the examiner has already stated that Podgorny does not show this feature. 

With regard to point 3, since each demon ("client manager node") is assigned exclusively to a single 
client, and communicates only with an associated user module ("message manager node"), Podgorny 
discloses point-to-point communication between the demon (on behalf of the client) and the user 
35 module ("message manager node") and does not disclose multicasting. Furthermore, since each user 
module ("message manager node") is assigned exclusively to one demon or client, Podgorny teaches 
away from using multicasting. 
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... according to the third way to match (i.e. user module = client manager node, message distribution = 
message manager node), Podgorny does not disclose 

5 1 . each client manager node (user module) of said group of client manager nodes comprising 

means for connecting to clients, means for managing client connections, means for forwarding 
messages received from message producing clients to message manager nodes (message 
distribution), and means for forwarding messages received from message manager nodes 
(message distribution )to message consuming clients. 
10 2. the server cluster further containing a group of message manager nodes (message distribution) 
being configured differently from the client manager nodes (user modules), said group of 
message manager nodes comprising a plurality of message manager nodes (message 
distribution). 

3. said messages comprising a destination information addressing a destination, said destination 
15 being at least one of a queue and a topic. 

With regard to point 1, since each demon ("client manager node") is assigned exclusively to a single 
client, Podgorny does not disclose or suggest the demon ("client manager node") connecting to a 
plurality of clients, but rather teaches away from such an interpretation. 

20 

With regard to point 2, Podgorny discloses only a single message distribution module ("message 
manager node"). Podgorny does not disclose or suggest to provide a plurality of message distribution 
modules, and further does not say how a system with a plurality of message distribution modules would 
be structured and operates. 

25 

With regard to point 3, the examiner has already stated that Podgorny does not show this feature. 

In summary, regardless of which way some features of Podgorny are matched with the claim features, 
and even if the teaching of Podgorny were combined with that of Codella, the remaining features 
30 would still not be suggested. 

Reconsideration is requested with respect to Claim 7 for the same reasons as were just discussed with 
respect to Claim 1 . 

35 Reconsideration is requested with respect to Claim 13 for the same reasons as were just discussed with 
respect to Claim 1 . 

With regard to claim 17, Podgorny does not disclose on the one hand a computer serving as a message 
manager node in a server cluster and communicating with a client manager across a multicast 
40 communications channel: the only broadcasting according to Podgorny takes place from the message 
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distribution 1350 to the user modules 1230a,b,c, that is, inside the server itselt. If the message manager 
node is identified with Podgorny's server 240 and the client manager is identified with Podgorny's 
demon 220, then the contradiction arises that according to Podgorny the communication between the 
server and the demons by its very nature is point-to-point, and not multicast. Reconsideration is 
5 requested. 

With regard to claim 21, it is noted that its last paragraph reads: 

wherein at least two message manager nodes are configured to comprise identical destinations, 
10 each of which is arranged to maintain a redundant copy of a message received in the course of 

the same multicast transmission from a client manager to said destination, said destination being 
at least one of a queue and a topic. 

The examiner is respectfully invited to point out where in the cited prior art this feature is disclosed. 
15 The applicant holds that this is not the case, and that this further feature allows the message server 
cluster to operate in a robust manner: in the case of failure of a message manager node, the backup 
message manager node may take over, or in the case the server cluster is split in separate parts (by a 
break in communications), the primary and the backup message manager node may operate 
independently and later again re-synchronise their status. 

20 

Dependent claims 

Claim 6: In addition to the arguments put forth with regard to claim 1, it is noted that Podgorny does 
not disclose: 

25 

a plurality of message manager nodes is provided, wherein at least two message manager nodes 
are configured to contain identical destinations to maintain one or more identical, redundant 
copies of stored data received in the same multicast transmission from a client manager as the 
original copy of stored data. 

30 

This holds for all three ways to match message manager nodes with elements of the Podgorny system 
(i.e. with the server, user modules or with the message distribution). It is requested that the Examiner 
point out where in the cited references this limitation may be found, or in the alternative to withdraw 
the rejection. 

35 

Claim 9: This claim addresses, as does claim 6, the operation of backup message managers. Thus the 
argument presented with respect to claim 6 is repeated with respect to claim 9. It is requested that the 
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Examiner point out where in the cited references this limitation may be found, or in the alternative to 
withdraw the rejection. 



Claim 10: nowhere in the prior art is it disclosed or suggested to associate a message manager with a 
5 channel rank and selecting, upon failure of a a primary message manager the associated backup 

message manager having the lowest or highest channel rank changes its status and becomes a primary 
message manager. It is requested that the Examiner point out where in the cited references this 
limitation may be found, or in the alternative to withdraw the rejection. 



10 Claim 11 is: 

The method of claim 7, wherein, if the message size exceeds a maximum message size value, 
said message to be transmitted between said message client and said message manager is 
fragmented by the message manager or by the message client and sent as a separate command. 

15 

It is requested that the Examiner point out where in the cited references this limitation may be found, or 
in the alternative to withdraw the rejection. 



Claim 12 is: 

20 

The method of claim 1 , wherein at least two multicast communication channels are present, and 
wherein either every client manager node is connected to all of said multicast communication 
channels and every message manager node is connected to only one of said multicast 
communication channels or every message manager node is connected to all of said multicast 
25 communication channels and every client manager node is connected to only one of said 

multicast communication channels. 

It is requested that the Examiner point out where in the cited references this limitation may be found, or 
in the alternative to withdraw the rejection. 

30 

Claim 14 is: 

The computer-readable medium of claim 13, wherein said computer readable code means for 
enabling the computer to establish a connection to a message client comprise means employing 
35 a library written in the Java language and conforming to the Java Message Service API. 

It is requested that the Examiner point out where in the cited references this limitation may be found, or 
in the alternative to withdraw the rejection. 

40 Claim 15 is: 



-24- 



The computer-readable medium of claim 13, wherein said computer readable code means 
comprise the following elements: a core module comprising session tasks and session command 
dispatchers, a client I/O module for routing commands, sending messages to a message client 
and receiving messages from a message client, said client I/O module comprising command 
5 routing means and connection management means, and a cluster I/O module for routing 

commands, sending messages to a message manager and receiving messages from a message 
manager, said client I/O module comprising command routing means and channel management 
means. 

10 It is requested that the Examiner point out where in the cited references these limitations may be found, 
or in the alternative to withdraw the rejection. 



Claim 16 is: 

15 

The computer-readable medium of claim 13, wherein said computer readable code means 
comprise configuration data, means for creating a digest of said configuration data and means 
for sending said digest to other client manager nodes and means for receiving a configuration 
data digest from other client manager nodes, as well as means for acquiring configuration data 
20 from other client manager nodes in case the digest of its configuration data and a received 

configuration data digest do not match. 

It is requested that the Examiner point out where in the cited references these limitations may be found, 
or in the alternative to withdraw the rejection. 

25 

Claim 17 is: 

A computer-readable medium having computer readable program code means embodied 
therein for enabling a computer to serve as a message manager node in a server cluster, the 

30 computer-readable medium comprising computer readable code means for enabling the 

computer to communicate with at least one client manager across a multicast communication 
channel, to receive message data from said client manager node, said message data comprising a 
destination information addressing a destination, depending on the destination information, to 
store said message data, to maintain a list of client subscriptions, and to compare the list of 

35 client subscriptions to available messages, and, when there is a match, for transmitting message 

information with a client information to a client server across said multicast communication 
channel. 

Claim 18 is: 

40 

The computer-readable medium of claim 17, wherein said computer readable code means 
comprise the following elements: a core module comprising a destination manager task, an 
admin manager task, a config distributor task, a reliability manager task an destination tasks, at 
least one destination command dispatcher, and a cluster I/O module for routing commands, 
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sending messages to a client manager and receiving messages and requests from a client 
manager, said client I/O module comprising command routing means and channel management 
means. 

5 It is requested that the Examiner point out where in the cited references these limitations may be found, 
or in the alternative to withdraw the rejection. 



Claim 19 is: 

10 The computer-readable medium of claim 17, wherein said computer readable code means 

comprise configuration data, means for creating a digest of said configuration data and means 
for sending said digest to other message manager nodes and means for receiving a configuration 
data digest from other message manager nodes, as well as means for acquiring configuration 
data from other message manager nodes in case the digest of its configuration data and a 

15 received configuration data digest do not match. 

It is requested that the Examiner point out where in the cited references these limitations may be found, 
or in the alternative to withdraw the rejection. 



20 Respectfully submitted, 



/s/ 

Carl Oppedahl 
25 PTO Reg. No. 32746 
telephone 970 468 8600 
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